Remarks 

1. Summary of the Office Action 

In the final office action mailed January 14, 2009, the Examiner rejected claims 19-20, 
22-28, 30-35, and 37-38 under 35 U.S.C. § 103(a) as being allegedly obvious over U.S. Patent 
No. 7,085,579 (Mizutani) in view of U.S. Patent No. 6,768,720 (Kamstra) and U.S. Patent No. 
7,088,698 (Harsch). Further, the Examiner rejected claims 21, 29, 36, and 39 under 35 U.S.C. § 
103(a) as being allegedly obvious over Mizutani in view of Kamstra and Harsch and fiirther in 
view of U.S. Patent No. 5,983,1 14 (Yao). 

The Examiner also objected to claims 37 and 38, because of a typographical error reciting 
that the claims depended fi-om claim 9 rather than from claim 34, but the Examiner indicated that 
the claims would be examined as though they correctly recited dependency from claim 34. 

2. Status of the Claims 

Applicant has amended each of the independent claims to include subject matter like that 
recited in dependent claims 26 and 33 (or originally in claims 6, 13, and 15), and Applicant has 
accordingly cancelled claims 26 and 33 to avoid redundancy. 

Applicant has amended claim 37 to correctly depend from claim 34 as noted by the 
Examiner. In addition. Applicant notes that claim 33 was intended to be a system claim 
depending from claim 27, rather than a method claim depending from claim 19; however, claim 
33 is now cancelled, so that point is moot. 

Applicant has also corrected typographical errors in claims 34 and 39 (changing the word 
"send" to the word "sent" in claim 34, and changing the word "a" to the word "the" in claim 39). 

Now pending are claims 19-25, 27-32, and 34-39, of which claims 19, 27, 34, and 39 are 
independent and the remainder are dependent. 



3. Response to Claim Objections 

As noted above, Applicant has amended claim 37 to correctly recite dependency from 
claim 33, thereby overcoming the objection of claims 37 and 38. 

4. Response to Claim Rejections 

As noted above, Applicant has amended each of the independent claims to recite subject 
matter like that recited in dependent claims 26 and 33 (now cancelled). Applicant submits that 
the invention recited by the independent claims, including (but not limited to) that added feature, 
patentably advances over the cited art and, therefore, that the independent claims are allowable. 

Further, Applicant submits that the Examiner clearly erred in rejecting dependent claim 
26, which had depended from claim 19 and had recited the claim element now expressly 
included in claim 19. 

In rejecting claim 26, the Examiner asserted that Mizutani teaches "wherein the keepalive 
signal is an empty Real-time Transport Protocol (RTP) packet" in that Mizutani teaches at 
Figures 18 and 19 a packet that does not carry multimedia (RTP) data in a PPP connection. 
Applicant submits that this analysis by the Examiner is clearly erroneous and does not properly 
justify the rejection of claim 26 (now claim 19), because the mere concept of a packet not 
containing any multimedia data does not mean that the packet is an empty RTP packet. 

Simply put, there is a clear difference between (i) a packet that does not contain 
multimedia/RTP data and (ii) an empty RTP packet. Applicant's claim feature is an "empty RTP 
packet", not merely an "empty packet" or a "packet not containing multimedia (RTP) data". 



The Examiner's analysis improperly reads the limitation "RTP packet" out of the claim 
altogether and instead reads the claim feature to be simply a packet that does not contain RTP 
data. In essence, this analysis by the Examiner seeks to equate a non-RTF packet (i.e., a packet 
that is not an RTP packet) with the actually-recited claim feature of an empty "RTP packet." 
Reading a limitation out of a claim like this, in an effort to establish obviousness, is 
inappropriate. 

At issue with respect to claim 26 (now claim 19) is whether the cited art reasonably leads 
to the claim feature of the keepalive signal (sent in response to detecting that the wireless device 
has neither sent nor received packet-based real-time media over the data-link layer connection 
for a threshold period of time, and sent from the wireless communication device into the radio 
access network (thus resetting the radio link timer) for transmission in turn to a destination in the 
packet-switched network) being an empty Real-time Transport Protocol (RTP) packet. 
Applicant submits that it does not. 

Applicant has not found in Mizutani, Kamstra, and Harsch any teaching of an empty RTP 
packet, and Applicant has not found any suggestion or reasonable motivation for one of ordinary 
skill in the art to modify the cited art so as to use an empty RTP packet for that purpose, and 
particularly to use an empty RTP packet as the keepalive signal in the context of Applicant's 
invention. That advantageous feature comes from Applicant's claims and specification, not from 
objective teachings in the cited art. 

One of ordinary skill in the art would readily understand and appreciate what an "empty 
RTP packet" is, particularly given the definition of an "empty RTP packet" provided in 
Applicant's specification at page 12, lines 17-21, which reads: 
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Further, the logic will preferably define the keepalive signal as particular packet 
data. For example, the keepalive signal could be an empty RTF packet. In this 
regard, according to RFC 1889, an RTF packet normally includes certain header 
fields (fixed header fields and, optionally, "RTF header extension" fields) and 
then payload data. A keepalive signal could be an RTF packet that does not 
include any payload data (e.g., zero length, or all zeros). 

This is even more so the case, given the well known nature of RTF and RFC 1889, as the 
specification states earlier at page 7, line 21 - page 8, line 1, that "[mjobile station 12, 
communication server 22 and client station 18 are each preferably equipped to engage in packet- 
based real-time media communications according to the well known Real-time Transport 
Protocol (RTF), which is defined by Internet Engineering Task Force (IETF) Request for 
Comments (RFC) 1889." 

Giving proper weight to Applicant's specification and to the well accepted knowledge of 
what RTF is, and properly considering the language of Applicant's claims, one of ordinary skill 
in the art would understand claim 26 (now claim 19) to recite that the keepalive signal is an 
empty RTP packet and would not have any reason to construe that claim feature to cover merely 
a packet that is not an RTP packet and that thus does not include RTP data. 

Because the cited art does not reasonably or logically lead to the invention recited by 
claim 26 (now claim 19), Applicant submits that the Examiner clearly erred in rejecting claim 26 
as being allegedly obvious over Mizutani in view of Kamstra and Harsch. As claim 19 now 
recites what claim 26 recited, Applicant submits that claim 19 is therefore allowable. 
Furthermore, Applicant submits that dependent claims 20-25 are allowable as well for at least the 
reason that they depend fi-om allowable claim 19. 
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Applicant also submits that independent claims 27, 34 and 39 are allowable as well for 
largely the same reason that claim 19 is allowable. Furthermore, Applicant submits that 
dependent claims 28-32 and 35-38 are allowable as well for at least the reason that they each 
depend from one of allowable claims 27 and 34. 

Applicant does not acquiesce in any assertion by the Examiner that is not expressly 
addressed by these remarks. 

For the foregoing reasons, Applicant submits that all of the pending claims are allowable, 
and Applicant therefore respectftiUy requests reconsideration and allowance. 

Should the Examiner wish to discuss this case with the undersigned, the Examiner is 
invited to call the undersigned at 312-913-2141. 

Respectfully submitted, 

MCDONNELL BOEHNEN 
HULBERT & BERGHOFF LLP 



Date: February 25, 2009 By; /Lawrence H. Aaronson/ 

Lawrence H. Aaronson 
Reg. No. 35,818 
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